The for...of loop is used to iterate over iterable objects—like Arrays, Strings, Maps, Sets, and NodeLists. It focuses on the values stored in the collection.
The for...in loop iterates over all enumerable properties of an object. In simpler terms, it looks at the keys (the names of the properties).
We have a bug in our shopping cart where we are trying to sum up prices in an array of items. The developer used a loop, but instead of adding the prices, the output is a weird string concatenation of indices. If I show you this loop, how would you debug why it's returning index strings instead of the actual item objects?
Imagine you're building a simple user profile card and you need to list out all the key-value pairs of a user's settings object. How would you loop through this object to render both the setting name and its value, and what happens if that object has inherited properties you don't want to show?
We recently integrated a legacy third-party library that modifies Array.prototype to add helper methods. Since then, several of our UI components that render lists are showing weird visual artifacts or extra list items at the bottom. What do you suspect is happening in our rendering loops, and how would you fix it without removing the library?
You're writing a utility function that needs to fetch data from an array of 5 API endpoints sequentially. You tried using a .forEach with async/await but noticed it fires them all concurrently. How would you restructure this loop using native JS iteration to ensure sequential execution, and why does that work?
We are building a custom high-performance Graph data structure class for a complex UI editor. We want other developers on the team to be able to loop over the nodes of this graph using standard JavaScript loop syntax without exposing the internal array or map. How would you design this class to support native iteration, and what are the performance trade-offs of your approach?
We are processing a stream of millions of log entries in a Node.js microservice. We need to parse them and yield them one by one to avoid loading the entire dataset into memory. How would you leverage generators and JS iteration protocols to handle this efficiently, and how does the engine handle the loop control flow under the hood?
You are designing a core state-management library for your enterprise. You want to expose reactive collections that developers can iterate over. How do you design the iteration interface using JS protocols so that it remains reactive, prevents memory leaks from dangling references, and maintains compatibility with standard JS loop constructs?
You've inherited a massive, 10-year-old codebase where for...in is used indiscriminately across arrays and objects, leading to intermittent production bugs due to prototype extensions. How would you orchestrate a safe, automated migration strategy to modern iteration patterns across hundreds of repos without breaking runtime behavior?